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Effectively planning the use and evolution of the DSN is a complex problem 
involving many parameters. This article discusses the tool that models many of 
these complexities , yet requires simple structured inputs and provides concise easy- 
to understand metrics to aid in the planning process . The tool , PC4CAST, is used 
for both load forecasting (predicting how well planned that DSN resources meet 
expected demand) and as a decision support tool in the capacity-planning process 
(determining the relative benefits of capacity expansion options ). It is now in use 
in the TDA Planning Office , has been used in numerous studies, and is also being 
used by the JPL Multimission Operations System Office (MOSO) as an integral 
part of Resource Allocation Team activities. Experience using the tool has helped 
to identify additional requirements that will further improve the planning process , 
which can be met by future PC4CAST versions . 


I. Introduction 

The DSN is a set of resources in high demand that 
requires careful planning to ensure its success in provid- 
ing telecommunications and radio astronomy services to 
its community of users. Design and construction of addi- 
tional DSN antennas take considerable time and money. 
For the DSN to remain responsive to its users, future re- 
source capacity and capability (e.g., transmitter/receiver 
frequency) to satisfy expected user demand must be deter- 
mined well in advance. When there is mismatch between 
resources and user requests, analysis is required to deter- 
mine what additional resources are required and/or how 
the user demand can be modified [1]. Because of fund- 
ing and schedule constraints, long-range planning typically 


involves a cost-benefit comparison of numerous capacity- 
expansion options. 

Analysis to support this planning can be visualized 
along a spectrum. At one end is the amount of user de- 
mand that can be satisfied by a static view of DSN re- 
sources (i.e., the current set of antennas and any planned 
additions, upgrades, and removals). This approach is most 
applicable for evaluating the fit between the DSN evolution 
plan and the current set of mission requirements. At the 
other end is fixed user demand and the resource set (i.e., 
number, type, location, etc.) necessary to satisfy it, ex- 
cluding issues of available funding and construction sched- 
ule constraints. The systems view, at the intersection of 
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these two views, considers both ends of the spectrum and 
provides trade-offs between user support and resource aug- 
mentation. For cost-effective planning of TDA resources, 
a planning tool must provide analysis appropriate to the 
problem. 

The PC4CAST tool supports this spectrum of planning 
analysis in an integrated, consistent, accurate, and timely 
manner. The structure of analytical inputs (e.g., user re- 
quests, resource availability, and geometric constraints be- 
tween user target and resources) is consistent for all types 
of analyses, while the type of output metrics may be chosen 
to fit the analysis being performed. The tool statistically 
models how user requirements would be accommodated 
without having to generate detailed schedules. PC4CAST 
is used both to forecast the DSN’s ability to support any 
given mission set and to identify the DSN resources re- 
quired for varying levels of mission support. A major ca- 
pability of the tool is analysis of the marginal impact of 
new missions and new capacity. 

Different approaches are required for planning the 
34-m/70-m ground resources (which primarily support 
deep-space missions) than those required for 26-m and 
smaller resources (which typically support Earth-orbiting 
missions). The operational version of PC4CAST is de- 
signed to facilitate planning of the 34-m/70-m resources. 
A prototype PC4CAST is currently under development, 
which will model stochastic demand for 26-m and smaller 
resources. The balance of this article will focus on the 
operational capabilities of, and products from, PC4CAST 
for 34-m/70-m ground resources. 


II. System Architecture 

The PC4CAST tool consists of a spreadsheet-based 
user interface and a forecasting engine (see Fig. 1). 
Microsoft Excel version 4.0 is used for both input of 
problem-dependent, parameters and graphical display of 
forecasting metrics. A forecasting engine, written in the 
language, uses information entered into Excel, along 
with problem-independent information stored in data- 
bases, and provides the raw forecasting results. The Mi- 
crosoft Windows environment seamlessly integrates Ex- 
cel and the forecasting engine, so the separation of in- 
put/output functions from processing is invisible to the 
user and does not affect tool operation. This architec- 
ture takes advantage of the capabilities of standard com- 
mercial off-the-shelf products, allowing more development 
effort to be spent on design of the forecasting and capac- 
ity/capability planning algorithms. 


Inputs and outputs are maintained in a type of Excel 
file called a workbook (a file which may contain multiple 
spreadsheets and charts) [2]. Each forecasting workbook 
represents one calendar year of a study. It contains spread- 
sheets for forecasting inputs, and both spreadsheets and 
charts for forecasting outputs. Inputs are entered by week, 
while results are output by week and month. The spread- 
sheet interface allows output formats to easily evolve with 
demand for different ways to view forecasting results. In 
addition, Excel users are able to design their own output 
formats to suit the needs of a particular study. 


III. Inputs 

Inputs to the PC4CAST tool can be grouped into three 
categories: user requirements, resource-capacity descrip- 
tion, and view periods. User requirements are input in the 
same format that the JPL Multimission Operations Sys- 
tems Office (MOSO) gathers and maintains them. This 
format is concise, yet of sufficient detail to allow accurate 
modeling of the user demand. Resource-capacity descrip- 
tions include each antenna’s planned availability and any 
options for future capacity changes. View periods (times 
when a particular object is in view at a particular antenna) 
represent the intersection of the user and ground resource 
domains. The tool requires all mission view periods (typ- 
ically one view period per station per day for deep-space 
objects) for the time period to be forecast. 

User requirements are entered and stored in a spread- 
sheet within a forecasting workbook (Fig. 2). Require- 
ments for all users of the resources must be input including 
those from spacecraft, ground-based scientific users such 
as Goldstone Solar System Radar (GSSR), High Resolu- 
tion Microwave Survey (HRMS), and Radio Astronomy 
and Special Activities (RASA), and those for the DSN’s 
own use (e.g., antenna calibration, maintenance). User re- 
quirements include the number of tracks or resource usages 
required each week and the following parameters: view 
period object (e.g., Cassini), user description (e.g., GSSR 
Mercury), usable resources, average and minimum dura- 
tions for tracks in each week of this requirement, and pre- 
and post-calibration time, which includes antenna setup 
and tear-down overhead before and after each track. The 
set of resources that are able to satisfy the requirement is 
represented by the usable-resources parameter, described 
below. 

The PC4CAST tool allows a requirement’s usable re- 
sources to be stated in a variety of ways. Usable resources 
may be specified by antenna (eg., DSS 14 or 14 for the 
70-rn antenna at Goldstone) or subnet (eg., 70M, 34S, 
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34H). Antennas and/or subnets may be combined to rep- 
resent antenna arrays, the simultaneous use of two or more 
antennas, or resource equivalents, when two or more re- 
sources can satisfy a requirement. For example, 70M, 
34S/34H” represents a requirement that can use either a 
70-m antenna or an array of 34S and 34H antennas. 

Available resources are described by resource defini- 
tions, scenarios (evolution paths), and downtimes. Re- 
source definitions simply define each resource by its code, 
location (i.e., which Deep Space Communications Com- 
plex), and subnet. This tool also provides network aug- 
mentation studies by maintaining multiple resource sce- 
narios, each including the initial on-line and final off- 
line dates for each current and planned resource. The 
PC4CAST operator chooses the appropriate scenario 
based on the study to be performed. Resource downtimes 
represent extended periods of time when a particular re- 
source is taken down. Regular antenna maintenance is 
treated as a user requirement, since this best models the 
scheduling environment. 


IV. Outputs 

The PC4CAST system has several different output 
metrics, each providing a different slice through detailed 
antenna-usage information. The calculation of expected - 
usage profiles is discussed in detail in Section V, but a 
quick description is necessary here. The software uses the 
input user requirements, resource scenario, and view peri- 
ods to calculate a detailed view of the expected demand on 
each antenna throughout the study time period. Figure 3 
is an example of the expected demand on one antenna for 
one week. The expected-usage profile provides the raw 
data from which many concise, useful metrics may be de- 
rived. 

One primary metric used in forecasting studies is the 
amount of user community requirements that cannot be 
satisfied given the resource capacity defined by the input 
resource scenario and downtimes. In PC4CAST, this un- 
served user demand is labeled lost time. It is calculated as 
the hours that cannot be supported, and is usually output 
as a percentage of the total hours of user requirements on 
a per-subnet basis (Fig. 4). This is a convenient level of 
aggregation since each subnet usually has its own commu- 
nity of users. Lost-time information can be presented at 
varying levels of aggregation (e.g., the whole network) as 
required by the study being performed. Besides showing 
how the current resource implementation plan can support 
current user requirements, lost-time information may be 
used to compare the relative merits between two resource 


scenarios or the impact of adding, removing, or modifying 
a user’s requirements. 

Whereas the lost-time metric is from the users’ point of 
view, the load-duration curve presents user demand from 
the ground resources’ perspective. This metric has been 
successfully used in the electric power utilities industry 
for management decision making on cost-effective capac- 
ity evolution [3]. It shows the percentage of time that a 
resource can expect various levels of demand (load). The 
load-duration curve for the 70-m subnet for 1995 (Fig. 5) 
reveals that demand exceeds capacity for half of the year. 
Moreover, there is demand exceeding 200 percent of capac- 
ity for roughly 8 percent of the year (about one month). 

The load-duration curve displays the full range of user 
demand relevant to capacity planning over the time period 
of interest. The y-axis intercept shows the value of peak 
expected usage, and the shape of the curve displays the 
proportion of time that demand is above, at, or below ca- 
pacity. When the user load is above capacity (greater than 
1.0), opportunities exist for adding capacity from DSN and 
non-DSN sources and/or managing user loads. When user 
loads are under 1.0, the ground system has the poten- 
tial for accommodating other missions, if there is a favor- 
able view period, or non- view period-constrained missions 
such as HRMS. Opportunities for, and benefits of, load 
management can also be quantified. Postponing a user’s 
period of high demand so that it does not coincide with 
another user’s can have a leveling effect by shifting load 
from the left side of the curve to the right. Reducing a 
user’s required minimum track duration can have a sim- 
ilar effect on the shape of the curve. Reducing pre- and 
post-calibration times will usually reduce the height of the 
curve at all points. The impact of these and other assump- 
tions, such as resource scenarios and mission sets, may be 
examined by comparing the shape of a load-duration curve 
generated with these inputs to a baseline curve. 

Another useful metric, which is shaped somewhat like 
the load-duration curve, is the resources-versus-lost-time 
graph. This graph shows how the percentage of unsatisfi- 
able requests varies with changing resource capacity. Con- 
versely, it can be viewed as showing what resource capac- 
ity is necessary to satisfy a certain percentage of user re- 
quirements. This metric should be used with some caution 
relative to nonintegral subnet values since the location of 
antenna sites impacts the ability to satisfy user loads. For 
example, Fig. 6 suggests that there would be 31 percent 
lost time if only one subnet were available and 3 percent 
if there were two 70-m subnets. But, the implication that 
1-2/3 subnets (i.e., 5 antennas) would result in 8 percent 
lost time is highly dependent upon antenna location and 
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the declinations of the spacecraft involved. In cases like 
this, the metric provides direction for further analysis of 
additional antenna-placement strategies. 

The trade space graph displays the information con- 
tained in multiple resources-versus-lost-time graphs as the 
number of resources required for a few selected lost-time 
levels over multiple years. Figure 7 shows the number 
of 34-m subnets that is required to provide four differ- 
ent levels of lost time (0, 5, 10, and 20 percent). Since 
the absolute lost- time value is dependent on many factors, 
including how much filtering has been performed on the 
user requirements and how many missions are in prime 
phase, no one level of lost time can always be considered 
acceptable. Nevertheless, this graph does help to define 
the trade space where the cost of additional resources must 
be weighed against the cost of losing scientific data due to 
unsatisfied user requirements. 

The PC4CAST system’s library of metrics can be used 
to analyze problems in both load forecasting and capac- 
ity planning. The current status of user support can be 
measured with the lost- time metric. Load-duration curves 
can be used to assess the marginal benefits of adding re- 
source capacity and/or capability. Cost-effective capacity 
evolution paths may be identified using resource-versus- 
lost-time and trade space graphs. Together, these metrics 
provide an internally consistent package to aid DSN man- 
agement decision making. 


capacity, and view period information. As stated ear- 
lier, the goal of this process is to determine the expected 
level of demand for all time periods within the study time 
frame. The first stage is to calculate an expected-usage 
value for each requirement. This value represents a time- 
weighted distribution of the requirements over the view pe- 
riod length. Second, this expected usage value is used with 
the view periods and the required tracking overhead to 
generate individual expected-usage profiles. Each of these 
profiles represents the demand from that requirement for 
each point in time for each antenna. Third, all individ- 
ual expected-usage profiles for each antenna are summed, 
resulting in one expected-usage profile for each antenna. 
These expected-usage profiles are the product of the first 
phase of the algorithm. Each of these three stages will be 
now discussed in detail. 

The following describes the calculation of the expected- 
usage value for one requirement in one week; each require- 
ment and each week are processed in a similar manner. 
First, the total amount of requested time is calculated 
from the requirement’s average duration, pre- and post- 
calibration times, and the number of tracks requested in 
the week, as follows: 

requested time = number of tracks 

x (average duration + precal. + postcal.) 


V. Algorithms 

The PC4CAST system uses a statistical approach that 
provides quick run time and models how user requirements 
would be scheduled, without actually generating schedules. 
Figure 8 is a process flow chart that gives a graphic presen- 
tation of the PC4CAST forecasting engine algorithm. This 
algorithm can be divided into two main phases. The first is 
the calculation of expected-usage profiles from forecasting 
inputs (user requirements, resource-capacity descriptions, 
and view periods). The second is the derivation of higher 
level metrics from expected-usage information. Presently, 
each week of a study year is calculated separately. Fore- 
casting metrics for one year of inputs are calculated in 
around five minutes, running on a 486-based computer. 
The system design allows for relatively easy modification 
to other time granularity, should the need arise in the fu- 
ture. 

A. Calculation of Expected-Usage Profiles 

The calculation of expected-usage profiles is a three- 
stage process that incorporates user requirements, resource 


Calibration times are included because they represent de- 
mand on the resources just as the actual track does. The 
next step is to find all usable view periods for the resources 
specified in the usable resource field that are long enough 
to support this requirement. In other words, the individ- 
ual view period duration must not be less than the require- 
ment’s minimum duration. Then, request slots are defined 
as usable view periods with pre- and post-calibration ap- 
pended to them. Request slots are defined this way be- 
cause the time before and after each view period represents 
time when the calibrations could take place and still have 
the track within the view period. The request slot time is 
then calculated as the sum of all request slot durations. 


request slot time = duration (request slot) 

all request slots 


Finally, the expected-usage value is calculated as 


expected usage = 


requested time 
request slot time 
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The expected-usage value therefore represents the percent- 
age expectation that when the requirement can use an an- 
tenna (constrained by the minimum duration constraint), 
it would use it or be scheduled to use it. 

If the expected usage is greater than 1.0, the require- 
ment cannot be supported by the resources it specified. 
This is caused by physical constraints such as positions of 
antennas and users, required view period mask, and overly 
restrictive requirements; it is not due to competition with 
other users. The system informs the analyst of any infeasi- 
ble requests at the end of the attempted run. It is then the 
analyst's responsibility to modify the requirement until it 
is feasible. This can be accomplished by one or more of the 
following means: adding to the usable resources field; or 
reducing the minimum duration, average duration, precali- 
bration, post calibration, or number of tracks. Forecasting 
metrics will not be generated until all requirements are 
feasible. 

The next stage is to generate individual expected-usage 
profiles for each requirement on each antenna requested. 
These are defined as stepwise constant functions, which 
can be visualized as the expected-usage value assigned to 
each request slot. 

The final stage involves the creation of an expected- 
usage profile for each antenna from all individual expected- 
usage profiles for that antenna. Each individual profile is 
summed to a total expected demand for each antenna over 
the study period. Figure 9 graphically shows the gener- 
ation of an expected-usage profile for a hypothetical mis- 
sion set. This sample profile is used in the next section 
to help describe how PC4CAST high-level metrics are de- 
rived from expected-usage profiles. 

B. High-Level Metric Derivation 

Once the expected-usage profiles are calculated for all 
requested antennas, many high-level metrics may be de- 
rived from them. The derivation of the most frequently 
used metrics — lost time, load-duration curves, resource- 
versus-lost-time graphs, and the trade space graph — are 
discussed below. 

Within PC4CAST, lost time is defined as the area of the 
expected-usage profile that is above one expected-usage 
unit (Fig. 10). Since the antennas that are being modeled 
can support only one user at a time, any expected usage 
over 1.0 represents time that cannot be supported. This is 
insupportable user demand or lost time. While lost time is 
calculated by antenna, the values for all antennas in a sub- 
net are usually summed to give the lost time for the sub- 
net. This subnet lost time is then charted as a percentage 


of the requested time on that subnet. Lost time is calcu- 
lated on a per- week basis, but may be aggregated to any 
longer time periods, such as monthly or quarterly. Paren- 
thetically, it should be noted that subnet requested time is 
simply the sum of the areas of expected-usage profiles for 
each antenna in the subnet. The lost-time metric captures 
the essential information contained in the expected-usage 
profiles and provides a concise measure of the impact of 
the input resource scenario upon user requirements. 

Load-duration curves include all expected usage-level 
information, but aggregate the time-of-day information to 
a level more useful for capacity planning. An easy way to 
visualize a load-duration curve is as an expected-usage pro- 
file with the highest peaks sorted to the left and the lowest 
usage levels to the right (Fig. 11). The load-duration curve 
is generated for each antenna, but may be aggregated to 
the subnet level. 

The resources- versus-lost- time graph displays lost time 
for a range of hypothetical resource capacities. The lost- 
time metric is usually calculated based on the fact that an 
antenna can support only one user simultaneously. But, 
for this graph, it is calculated with an assumed resource 
capacity ranging from zero to the highest expected-usage 
level (Fig. 12). As with the load-duration curve, these 
graphs can be used at the antenna or subnet level. This 
results in a graph that contains some immediately obvious 
data points. For instance, a resource capacity of zero re- 
sults in 100 percent lost time; likewise, capacity equal to 
the highest expected usage results in no lost time (but very 
low capacity utilization). Also, the lost-time value for a 
capacity of one resource corresponds to the usual lost-time 
metric. The value provided by the resources-versus-lost- 
time graph is the identification of how addition or removal 
of ground resources will impact the users. 

The trade space graph (Fig. 7) is derived from the 
resources- versus-lost- time graph for a few selected lost- 
time values. Each line on the graph corresponds to the 
resources required to provide for a lost time less than or 
equal to the selected level. The required-resources value 
is calculated by reading, on the resources-versus-lost-time 
graph, the number of subnets required for the selected lost- 
time level. This value is then rounded up to the nearest 
whole antenna (e.g., 1.5 subnets becomes 1-2/3 subnets, 
or 5 antennas). 


VI. Future Potential 

To date, PC4CAST has proven to be helpful in load 
forecasting and capacity-planning analysis. Experience 
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with the tool has identified requirements for further al- 
gorithmic enhancements which would provide improved 
modeling of the DSN system, more accurate metrics, 
greater insight into the distribution of lost time, and mea- 
sures of augmentation cost effectiveness. The definition of 
a user requirement’s usable resources could be extended 
to include required antenna size and additional equipment 
parameters such as transmitter and receiver frequencies. 
Lost time would be redefined to include not only requested 
time that is unsupport able because of competition, but 
also requests made infeasible by an antenna being down. 
Also, definition and implementation of a priority scheme 
would allow the lost-time and load-duration curve metrics 
to be disaggregated to the level of prioritized mission sets 
or even individual users. Resource augmentation costs and 
the value of user support would also be included to bet- 
ter support the decision-making process. These features 


would provide for improved analysis of the marginal ben- 
efits of resource evolution paths. 

Earth-orbiting missions have not been modeled in this 
implementation of PC4CAST. Accurate calculation of the 
required view period knowledge for all users and time 
frames of interest is usually not a problem for the deep- 
space missions that normally request time on the 70- and 
34-m antennas. The Earth orbiters that typically request 
the 26-m and smaller antennas have far less predictable 
view periods. The Systems Analysis Section has been de- 
veloping probabilistic methods to model such users where 
view periods cannot be calculated very far into the future. 
This work has followed the general PC4CAST paradigm 
so the two approaches could be readily integrated to pro- 
vide a comprehensive DSN load-forecasting and capacity- 
planning tool. 
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Fig. 1 . Overview of the PC4CAST forecasting system. 







USER LOADING PROFILE - 1997 
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Fig. 2, User requirements input spreadsheet for 1997. 
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Fig. 4. Monthly lost-time chart for 1997. 
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Fig. 6. Resources-versus-iost-time graph for the 70-m subnet in 1995. 






Fig. 8. PC4CAST forecasting engine process flow chart. 
















Fig. 11. Derivation of a load-duration curve from a hypothetical expected-usage profile. 



Fig. 12. Derivation of a resources-versus-lost time chart from a hypothetical 
expected-usage profile. 








